The Work Item “Further EUL Enhancements” has been agreed in 3GPP Release 12. One aspect is improving the EUL coverage via improved Transmission Time Interval (TTI) switching (e.g., switching between 10 ms TTI and 2 ms TTI). To assist with TTI switching, a High Speed-Shared Control Channel (HS-SCCH) order with the specific value is sent from the serving network nodes (such as a Node B) to the user equipment (UE) to perform the TTI switching.
The decision to trigger the TTI switch (e.g., 2 ms to 10 ms or 10 ms to 2 ms) can be taken autonomously by the serving network node or by a radio network controller (RNC), such as a serving RNC. In the case that the RNC makes the decision, the RNC will need to inform the serving network node of this decision, and the serving network node should send the HS-SCCH order to the UE so the TTI switching process can be started. According to legacy procedures, the HS-SCCH order is sent at the reception of RADIO LINK RECONFIGURATION COMMIT message. There are different interpretations, however, of how much the RNC can control. For example, the RNC may request the network node to send the HS-SCCH order in a different way (i.e., alternative way) than what is specified in the legacy system.
When TTI switching is performed, the network node and UE should do the hand shake (i.e., the network node sends a HS-SCCH order to the UE and the UE sends back the acknowledgement). The UE will go to the new TTI according to the specification. At the network node side, there are different ways to let the network node go to the new TTI. According to legacy procedures, Radio Link Reconfiguration is used.
In the current RAN3 NBAP and RNSAP specification (TS 25.433 and TS 25.423), there is a legacy procedure that the HS-SCCH order is sent at the reception of RADIO LINK RECONFIGURATION COMMIT when synchronized Radio Link Reconfiguration procedure is used. If an alternative solution is introduced to request Node B to send the HS-SCCH order in a different message, or in a specified time when using the synchronized Radio Link Reconfiguration procedure, this will cause ambiguity.
If the RNC requests that the network node send the HS-SCCH order in the alternative way, but the network node does not support the alternative way, then the network node may ignore the request from the RNC. The RNC, however, may not be informed that the request was ignored by the network node. If the network node understands there is an ongoing TTI switching operation, the network node may send the HS-SCCH order when a RADIO LINK RECONFIGURATION COMMIT message is received. If the network node does not understand there is an ongoing TTI switching operation, the network node will not send any HS-SCCH order. If the network node sends the HS-SCCH order at the reception of the RADIO LINK RECONFIGURATION COMMIT message, the TTI switching operation can be performed, but since the RNC and the network node have different understanding on when the HS-SCCH order is sent, it may cause the network node to switch to the new configuration at the wrong time. This may cause further network node and UE mismatch. If the network node does not send any HS-SCCH order, then at the reception of the RADIO LINK RECONFIGURATION COMMIT message, it will follow the legacy procedure and go to the new configuration (for example, new TTI). This is likely to cause problems, as the UE will still be using the old configuration.
There may also be ambiguity when the network node only supports the alternative way, but not the legacy way. For example, if the RNC uses the legacy way, it considers that at the reception of the RADIO LINK RECONFIGURATION COMMIT message, the Node B shall send HS-SCCH order to the UE. If the network node does not support the legacy way, the network node would not send any order. In such a case, when the network node receives the RADIO LINK RECONFIGURATION COMMIT message, it will go to the new configuration according to the current specification, but the UE will still be using the old configuration.